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A  Network  Pump 
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Abstract — A  designer  of  reliable  multi-level  secure  (MLS)  networks  must  consider  covert  channels  and  denial  of  service  attacks  in 
addition  to  traditional  network  performance  measures  such  as  throughput,  fairness,  and  reliability.  In  this  paper  we  show  how  to 
extend  the  NRL  data  Pump  to  a  certain  MLS  network  architecture  in  order  to  balance  the  requirements  of  congestion  control, 
fairness,  good  performance,  and  reliability  against  those  of  minimal  threats  from  covert  channels  and  denial  of  service  attacks.  We 
back  up  our  claims  with  simulation  results. 

Index  Terms — Covert  channel,  flow  control,  gateway,  information  theory,  router,  security. 
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1  Introduction 

multi-level  secure  (MLS)  system  stores  and  processes 
information  of  different  sensitivity  levels  in  a  secure 
manner.  By  this  we  mean  that  access  is  controlled  so  that  no 
high  level  information  is  allowed  to  pass  to  lower  level 
users/ processes  (Low)  but  lower  level  information  is  avail¬ 
able  to  higher  level  users /processes  (High)  [3]. 

Thus,  an  MLS  system  allows  Low  to  send  messages  to 
High,  but  High  should  not  be  able  to  send  messages  to 
Low.  On  the  other  hand,  acknowledgments  (ACK)  to  Low 
that  High  has  received  its  messages  are  necessary  for  reli¬ 
ability  and  performance.  This  is  especially  true  for  distrib¬ 
uted  systems  in  which  the  communication  channels  may 
not  always  be  reliable.  High,  however,  can  manipulate  the 
times  that  ACKs  arrive  in  order  to  covertly  send  unauthor¬ 
ized  messages  to  Low.  Therefore,  we  see  that  MLS  security 
is  in  conflict  with  the  need  for  functionality. 

The  Pump,  developed  at  NRL  [6],  17],  solves  the  di¬ 
lemma  of  simultaneously  assuring  reliability,  performance, 
and  security  when  there  is  only  one  Low  and  one  High.  We 
will  refer  to  this  as  the  basic  Pump.  The  basic  Pump  allows 
High  to  send  ACKs  to  Low  indirectly  through  an  interme¬ 
diary  communication  buffer.  Further,  the  basic  Pump  re¬ 
quires  that  Low  receive  the  ACKs  at  probabilistic  time  inter¬ 
vals.  This  probabilistic  ACK  is  based  upon  past  High  activity. 

Since  computer  systems  are  becoming  more  open  and 
interconnected,  denial  of  service  problems  are  receiving 
more  attention  [21],  Hence,  security  devices  such  as  the 
Pump  should  also  provide  protection  against  such  attacks. 

This  paper  addresses  how  to  adapt  the  basic  Pump  for 
use  in  a  network  environment,  where  we  have  multiple 
Lows  and  multiple  Highs.  We  will  refer  to  this  as  the 
"network  Pump."  As  we  move  from  a  dedicated  data  net¬ 
work  to  the  Broadband  Integrated  Service  Digital  Network 
(B-ISDN)  such  as  the  Asynchronous  Transfer  Mode  (ATM) 
Network  [9],  the  issues  of  congestion  control,  fairness,  and 
reliability  become  extremely  important  and  extremely 
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complicated.  The  network  community  itself  has  not  worked 
all  of  these  issues  out  yet.  Our  problem  is  even  more  com¬ 
plex  because  we  are  coupling  security  (i.e.,  covert  channels 
[10]  and  denial  of  service)  with  the  above. 

1.1  Assumptions  and  Terminology 

The  network  environment  that  is  considered  is  shown  in 
Fig.  1.  Each  Low  (High)  is  at  the  same  low  (high)  level.  Pos¬ 
sible  implementations  of  the  network  Pump  are  a  packet 
switch  between  workstations,  a  router  connecting  local  area 
network  segments,  etc. 


Fig.  1 .  The  Pump  in  a  network  environment. 

There  are  many  Lows  (L,)  and  Highs  (I !,),  and  they  are 
untrusted  processes,  thus  they  may  contain  Trojan  Horses 
(malicious  software).  The  network  Pump  is  a  trusted  proc¬ 
ess  (assured  to  be  free  of  malicious  software)  which  medi¬ 
ates  traffic  from  Lows  to  Highs.  Each  message  that  will  be 
routed  from  a  Low  to  a  High  has  a  message  number  (ID), 
and  input  and  output  addresses  associated  with  it.  For  sim¬ 
plicity,  we  assume  that  all  messages  have  the  same  length. 
We  do  not  consider  multicasting  in  this  paper.  We  further 
assume  that  Lows  (Highs)  do  not  communicate  among 
themselves  to  simplify  the  covert  channel  analysis. 

A  session  is  a  connection  between  any  Low  and  any 
High.  In  Fig.  1  there  are  I  x  ]  distinct  sessions.  During  each 
session^,  a  message  leaves  L„  travels  over  link,,  goes  into 
the  network  Pump,  and  after  processing  leaves  the  network 
Pump  over  link,/  and  arrives  at  H(.  We  assume  that  all 
propagation  delays  are  zero  for  conceptual  simplicity.'  The 
minimal  processing  time  of  the  network  Pump  is  a  fixed 
overhead  value  Ov,  which  is  small  enough  so  that  the  net¬ 
work  Pump  itself  never  becomes  a  performance  bottleneck. 

1.  This  assumption  is  true  for  the  basic  Pump  also.  It  can  be  easily  relaxed 
in  both  cases. 
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The  demand  (input)  rate  is  the  rate  demanded  by  L, 
destined  for  H j.  Each  H;  behaves  as  a  server  with  service 
rate  This  is  the  inverse  of  the  mean  time  of  service  by 
for  messages  from  L,. 

1.2  Objectives 

Most  network  resources  are  dynamically  shared  for  effi¬ 
ciency  reasons.  If  this  dynamic  sharing  is  not  carefully  con¬ 
trolled,  then  inefficiency  and  delays  occur  [4],  The  main 
functions  of  congestion  control  in  a  network  are: 

•  To  prevent  inputs  from  sending  messages  faster  than 
the  outputs  can  handle  them. 

•  To  prevent  throughput  degradation  and  loss  of  effi¬ 
ciency  from  overloading  the  network. 

•  To  prevent  unfair  allocation  of  network  resources 
from  competing  inputs. 

Since  the  network  Pump  is  a  shared  resource  among  many 
sessions,  it  should  provide  the  congestion  control  mecha¬ 
nism.  Let  us  discuss  the  specific  objectives  required  of  the 
network  Pump. 

1.2. 1  Reliability  /  Handshaking 

The  reliability  requirement  can  be  simply  stated  as  no  loss  of 
messages  and  no  duplication  of  messages.  To  satisfy  this  re¬ 
quirement  ACKs  and  message  numbers  (ID)  are  necessary. 
The  network  Pump  has  a  reliability  protocol  that  works  as 
follows: 

If  a  Low  has  not  received  ACK  by  time-out  after  sending 
a  message,  it  will  retransmit  the  same  message.  If  a  High 
receives  the  same  message  then  it  will  keep  only  one  copy. 

Further,  a  Low  does  not  send  the  next  message  to  a  spe¬ 
cific  High  until  its  previous  message  to  that  High  has  been 
ACKed  (handshake  protocol). 

1.2.2  Performance 

We  desire  good  performance.  The  network  Pump's  control 
over  the  time  of  sending  the  ACKs  to  a  Low  can  be  utilized 
for  congestion  control.  The  network  Pump  is  designed  to 
exercise  congestion  control.  The  network  Pump  controls  the 
rates  into  itself,  the  realized  (input)  rates,  by  slaving  Low's 
message  transmission  to  the  average  rates  out  (service 
rates)  of  the  network  Pump.  It  does  so  by  moderating  the 
ACK  rate  to  a  Low,  since  this  Low  will  not  send  a  new  mes¬ 
sage  until  it  receives  an  ACK  from  the  previous  message 
from  the  same  session  (the  handshake  protocol). 

If  the  service  rates  are  greater  than  the  demand  rates, 
then  the  network  Pump  should  not  hurt  performance.  If 
service  rates  or  output  capacities  are  less  than  the  demand 
rates,  then  the  outputs  cannot  handle  their  inputs.  There¬ 
fore,  the  network  Pump  by  slowing  the  demand  rate  to  the 
realized  rate,  alleviates  congestion,  and  at  the  worst,  does 
not  lessen  total  throughput. 

1.2.3  Fairness 

Bandwidth  of  communication  links,  transmission  speed, 
and  processing  speed  are  all  limited.  Therefore,  if  the  load 
of  data  traffic  offered  to  the  network  Pump  exceeds  its  ca¬ 
pability,  some  of  the  load  must  be  cut.  The  load  must  be  cut 
fairly  for  all  the  sessions  that  share  the  network  Pump.  The 
idea  is  shown  in  Fig.  2  where  the  illustrated  output  limita¬ 


tion  is  due  to  limited  output  link  capacity.  Note,  in  denial  of 
service  attacks  (discussed  later),  the  limitation  is  usually 
due  to  decrease  in  the  High  service  rate. 


Demand  Rate  Realized  Rate 


Fairness  can  be  defined  in  different  ways.  One  fairness 
policy  is  max-min  fairness.  This  policy  says  all  sessions 
should  get  bandwidth  according  to  the  following  crite¬ 
rion — the  smallest  realized  rate  is  as  large  as  possible  and, 
given  this,  the  second-smallest  realized  rate  is  as  large  as 
possible,  etc.  [5],  For  example,  if  there  are  three  sessions 
whose  demand  rates  (units  of  messages  per  unit  time)  are 
0.4,  0.5,  0.6  and  the  output  capacity  equals  1,  then  all  three 
sessions  will  have  realized  rates  of  1/3,  1/3,  1/3  under 
max-min  fairness.  If  one  session  demands  less  than  what  it 
can  get,  the  leftover  bandwidth  will  be  equally  shared 
among  the  rest  of  the  sessions.  For  example,  if  there  are 
three  sessions  whose  demand  rates  are  0.2,  0.5,  0.6  and  the 
output  capacity  equals  1  then  those  sessions  will  have  real¬ 
ized  rates  0.2,  0.4, 0.4,  respectively,  under  max-min  fairness. 

The  advantages  of  this  policy  are  1)  there  is  a  simple  way 
to  implement  this  policy  (i.e.,  round-robin  scheduling  [5]) 
and  2)  the  scheduling  scheme  does  not  need  to  know  the 
demand  rates  of  sessions  which  may  not  always  be  known. 
Since  this  policy  gives  preference  to  sessions  that  have 
lower  demand  rate,  it  does  not  allow  a  session  to  take  the 
entire  bandwidth  if  there  is  more  than  one  session.  One 
disadvantage  of  this  policy  is  that  a  heavily  demanded  ses¬ 
sion  is  penalized  more  than  a  lightly  demanded  session 
(i.e.,  not  sensitive  to  demand  rates). 

There  are  other  fairness  policies,  such  as  the  proportional 
policy  [20].  This  policy  allocates  bandwidth  in  proportion 
to  each  input  demand  rate.  The  network  community  does 
not  have  a  "best"  fairness  policy.  The  network  Pump  uses 
max-min  fairness  because  of  the  above  advantages. 

1.2.4  Covert  Channels 

It  is  well  known  that  the  ACK  stream  that  is  required  to 
satisfy  the  reliability  requirement  introduces  covert  com¬ 
munication  channels.  This  was  the  motivation  for  devel¬ 
oping  the  basic  Pump  over  the  conventional  store  and  for¬ 
ward  buffer  type  of  communication.  We  will  show  in  Sec¬ 
tion  3.2,  using  results  from  [6],  [7],  that  the  capacity  of  the 
covert  channels  can  be  made  negligible. 

1.2.5  Denial  of  Service 

We  interpret  the  denial  of  service  attack  in  a  broad  sense  in 
the  network  environment: 

If  a  session  cannot  achieve  its  intended  throughput  due  to 

the  misbehavior  of  other  sessions  then  the  session  is  under  a 

denial  of  service  attack. 
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Since  the  network  Pump  is  a  shared  resource  among 
several  sessions,  services  for  other  sessions  can  be  poten¬ 
tially  disrupted  if  too  much  resource  is  allocated  to  one 
particular  session.  The  design  of  the  network  Pump  should 
prevent  such  a  situation. 

2  Background— The  Basic  Pump 

In  the  basic  Pump  our  concern  is  sending  messages  from 
(one)  Low  to  (one)  High.  In  [6],  [7],  [19],  we  reviewed  why 
traditional  communication  protocols  (including  read-down 
and  blind  write-up )  cannot  satisfy  the  needs  for  reliability, 
performance,  and  security  simultaneously.  As  a  solution, 
the  basic  Pump  was  introduced  as  shown  in  Fig.  3. 


Pump 


Fig.  3.  The  Basic  Pump. 


The  basic  Pump  [6]  places  a  buffer  (size  n)  between  Low 
and  High,  and  gives  ACKs  at  probabilistic  times  to  Low 
based  upon  a  moving  average  (MA)  of  the  past  m  High 
ACK  times.  A  High  ACK  time  is  the  time  from  when  the 
buffer  sends  a  message  to  High  to  the  time  when  the  buffer 
receives  High's  ACK.  Thus,  basing  Low  ACK  times  upon 
past  High  activity  has  the  double  benefit  of  1)  keeping  the 
buffer  from  filling  up  and  2)  having  a  minimal  negative 
impact  upon  performance.  The  Low  ACK  time  is  the  time 
from  when  Low  sends  a  message  to  the  basic  Pump  to  the 
time  when  Low  receives  the  basic  Pump's  ACK.  The  Low 
ACK  time  is  a  slightly  modified  exponential  random  vari¬ 
able  [7]  with  mean  equal  to  MA.  Intuitively,  the  modifica¬ 
tion  is  1)  a  truncation  of  the  exponential  density  at  a  design 
parameter  time_out  and  2)  a  shift  by  an  amount  of  time 
equal  to  the  minimum  processing  time  (Tr)  of  a  message  if 
there  is  space  on  the  buffer.  When  Low  must  wait  for  space 
on  the  buffer,  the  above  holds,  except  the  shift  is  equal  to  T, 
=  max(w ait  time  for  space,  minimum  processing  time). 
Thus,  the  Low  ACK  time  is  a  random  variable  that  takes 
values  between  Tr  and  time_out.  (In  [7]  we  have  slightly 
modified  this  over  the  first  exposition  of  the  basic  Pump  [6] 
to  introduce  extra  noise.  However,  for  the  network  Pump 
we  stay  with  the  simpler  formulation  due  to  the  extra  noise 
from  multiple  users  and  a  modified  ACK  scheme  (see  Sec¬ 
tion  3.2,  Covert  Channel  Analysis).) 

At  present,  an  implementation  of  the  basic  Pump  is  run¬ 
ning  on  a  XTS-300  platform  [14].  Early  results,  along  with  the 
simulation  results  of  Kang  and  Moskowitz  [7],  show  a  proof 
of  concept  for  the  basic  Pump.  Based  upon  this  and  the  need 
for  a  secure  network  congestion  mediator  we  feel  the  exten¬ 
sion  to  the  network  environment  is  proper.  Presently,  a  pro¬ 
totype  network  Pump  is  being  built  in  hardware  as  a  guard 
by  NRL's  Center  for  High  Assurance  Computer  Systems  [22]. 

3  An  Architecture  of  the  Network  Pump 

The  architecture  of  a  network  Pump  is  shown  in  Fig.  4. 


Fig.  4.  A  logical  view  of  the  network  Pump. 


Each  component  of  the  network  Pump  works  as  follows: 

Lows  and  Highs  (Exterior  to  the  Network  Pump).  Lows 
(Highs)  is  the  set  of  inputs  (outputs)  to  the  network 
Pump.  Lows  (Highs)  consists  of  I  (/)  processes  non¬ 
communicating  among  themselves.  Each  Low,  Lir  can 
strive  to  send  messages  to  any  High,  H„  with  various 
demand  rates  as  discussed  before.  Since  L;  is  outside  of 
the  network  Pump  we  assume  the  L,  has  some  procedure 
for  sending  messages  over  link,,  the  only  constraint  be¬ 
ing  that  the  demand  rates  are  /l,-,,  such  that  'ZjAjj  <  capac¬ 
ity  of  link,.  Consider  session,-, — after  L,  sends  a  message 
to  H j,  it  waits  for  the  ACK  to  that  message  from  the  net¬ 
work  Pump.  Once  this  ACK  arrives,  L,  can  send  another 
message  to  H,-.  Therefore,  each  Low  can  only  send  a  new 
message  in  each  session  after  it  has  received  the  ACK  of 
the  previous  message  from  the  network  Pump 
(handshake  protocol).  When  H,  receives  a  message  from 
the  network  Pump  it  sends  an  ACK  back  after  the  ap¬ 
propriate  service  time  to  the  network  Pump. 

Receivers.  There  is  a  receiver,  for  each  L,.  In  receiver,,  there 
are  /  slots;  slot,-  stores  a  messages  from  session, ;  until  it  is 
routed  by  the  TLP. 

Trusted  Low  Process  (TLP).  The  TLP  takes  a  message  from 
a  receiver  and  routes  it  to  the  appropriate  output  buffer. 
We  denote  by  Tr  the  time  from  when  a  message  is  sent 
from  a  Low  to  the  time  when  that  message  is  placed  in 
the  appropriate  output  buffer.  (We  will  also  refer  to  Tr  as 
"routing  time"  in  the  network  Pump.)  If  there  is  available 
space  in  the  output  buffer,  Tr  is  equal  to  the  overhead  Ov. 
If  there  is  no  space,  the  message  is  not  placed  until  there  is 
a  space  available.  Therefore,  T,.  includes  both  O,,  and  the 
amount  of  time  the  message  waits  until  the  output  buffer 
is  available.  After  the  message  is  routed  to  the  output 
buffer,  the  TLP  is  ready  to  send  an  ACK  back  to  the  ap¬ 
propriate  L,.  The  time  this  ACK  arrives  at  L,  depends  on 
the  randomization  scheme,  but  is  always  at  least  Tr. 

Output  Buffers.  There  are  I  logical  output  buffers  for  H,, 
each  denoted  as  buffer, y.  A  message  from  session,-,-  will  be 
stored  in  buffer, ,-. 

Trusted  High  Processes  (THP^).  THP,  delivers  a  message 
from  buffer, -,  to  H;-  according  to  a  scheduling  scheme. 
THP,  cannot  deliver  another  message  from  buffer,,  until 
the  prior  message  from  buffer,-,  is  ACKed  (by  H,). 

3.1  A  Detailed  Design 

A  detailed  design  rationale  is  described  in  this  section. 
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3. 1. 1  Trusted  High  Processes 

THP,  plays  an  important  role  in  scheduling  delivery  from 
output  buffers  to  H,  and  in  computing  moving  averages. 
Fig.  5  graphically  describes  the  role  of  a  THP,. 


Fig.  5.  A  closer  view  of  a  trusted  high  process. 

Consider  THP. — it  has  to  deliver  messages  from  each 
buffer  y  to  H;.  Since  the  capacity  of  link7  is  limited  by  physi¬ 
cal  considerations  and  inputs  may  send  more  messages 
than  link7  or  H,  can  handle,  THPy  needs  some  scheduling 
scheme.  This  scheduling  scheme  determines  the  fairness 
among  different  inputs. 

The  network  Pump  uses  round-robin  scheduling  because 
it  is  simple  and  achieves  max-min  fairness  [5].  For  example,  if 
THP,  has  to  serve  three  output  buffers  then  an  opportunity  to 
send  a  message  is  given  in  the  order  of  buffer y,  buffer2;, 
buffer3;,  buffer1;,  ....  If  buffer2/  does  not  have  any  message  to 
send  then  the  opportunity  is  transferred  to  buffer3;  and  the 
next  opportunity  is  given  to  buffer-^,  and  so  on. 

THP;  also  maintains  and  updates  moving  averages 
(MAy,  ...,  MAj  ).  The  reason  for  THPy  to  maintain  I  separate 
moving  averages  (i.e.,  one  per  session)  instead  of  one  com¬ 
bined  moving  average  is  that  H,  may  service  messages  from 
different  Lows  at  different  rates.  Throughout  this  paper  we 
assume  that  the  message  service  time  is  not  a  performance 
bottleneck  in  the  benign  case.  In  other  words,  the  bottleneck 
is  output  links,  not  servers,  unless  the  system  is  under  de¬ 
nial  of  service  or  covert  channel  attacks. 

Since  there  is  potentially  more  than  one  input,  the 
method  of  computing  moving  averages  is  different  from 
when  there  is  only  one  input.  When  there  is  only  one  input, 
the  moving  average  is  computed  based  on  the  interval  from 
the  time  the  message  is  sent  to  High,  to  the  time  the  ACK 
arrived  from  High.  However,  if  there  is  more  than  one  in¬ 
put,  the  message  is  ready  to  be  sent  by  the  Pump,  but  can¬ 
not  be  sent  because  the  output  link  is  not  available  due  to 
the  round-robin  scheduling.  This  additional  waiting  time 
must  be  taken  into  account  or  else  the  input  messages  will 
flood  the  output  buffers. 

Specifically,  MA,y  of  the  network  Pump  is  the  moving 
average  of  the  last  m  ACK  times  from  H,  to  buffer;,-.  An 
ACK  time  from  H,  is  the  difference  between  when  buffer, 
receives  ACK  from  H;-  and  maxitime  that  message  arrived  in 
buffer;,-,  time  that  the  previous  message  from  buffer, y  was 
ACKed  by  H,-).  In  other  words,  if  buffer;,-  is  not  empty  then 
the  previous  ACK  time  by  H,  is  used  to  compute  the  mov¬ 
ing  average.  However,  if  buffer,,  is  empty  when  a  new  mes¬ 
sage  arrives  then  we  use  the  arrival  time  instead  of  the  pre¬ 
vious  ACK  time. 


3. 1.2  Output  Buffers 

The  number  of  messages  in  buffer ,-,-  is  important  to  achieve 
fairness  [5]  (the  bigger  the  number  of  messages  in  buffer, y 
the  fairer).  This  is  because  our  round-robin  scheduler  does 
not  take  burstiness  into  account.  The  way  to  handle  bursts 
is  to  have  enough  messages  queued  in  buffer, y  so  that  times 
of  abundance  and  starvation  (with  respect  to  message  arri¬ 
vals)  are  balanced  out.  In  fact,  it  is  desirable  to  keep  the 
queue  length  in  buffer,,  positive  so  that  max-min  fairness  is 
preserved.  However,  if  the  queue  length  is  too  big  we  have 
potential  covert  channel  and  denial  of  service  problems. 
Thus,  it  is  desirable  to  keep  the  queue  length  at  a  certain 
level.  To  address  this  issue,  we  introduce  the  concept  of  Fair 
size,  which  is  a  design  parameter  targeted  for  the  desirable 
queue  length.  Intuitively,  the  burstier  the  input,  the  larger 
the  Fair  size  must  be.  Note  that  Fair  size  has  to  be  intelli¬ 
gently  chosen  so  that  one  session  cannot  dominate  (fill)  the 
total  output  buffer  and  at  the  same  time  large  enough  to 
accommodate  burstiness.  Good  design  requires  that  the 
total  output  buffer  has  at  least  Fair  size  surplus  spaces  in 
addition  to  sum  of  the  Fair  size  spaces  allocated  for  all  ses¬ 
sions.  Intuitively,  if  all  sessions  are  active  and  behaving,  this 
design  leaves  us  with  at  least  Fair  size  spaces  in  the  total  out¬ 
put  buffer.  Fig.  6  pictorially  shows  buffer, y  where  the  number 
of  messages  in  the  buffer  fluctuates  around  the  Fair  size. 

Fair  size 


t 


Fig.  6.  A  closer  view  of  buffer, y. 

Since  the  network  Pump  has  a  built-in  mechanism  to 
share  output  buffers  fairly  among  different  sessions  (i.e., 
moving  average  construction  to  control  input  rates  which 
will  be  discussed  in  Section  3.1.3),  all  output  buffers  are 
dynamically  shared  among  different  sessions. 

3.1.3  Trusted  Low  Process 

When  routing  requests  arrive  from  receivers,  the  TLP 
routes  messages  to  the  proper  output  buffers  and  reads  the 
current  moving  average  value.  Once  the  message  is  deliv¬ 
ered,  the  TLP  is  ready  to  send  an  ACK.  However,  this  ACK 
will  be  delayed  depending  on  the  moving  average  of  the 
session  and  the  randomization  scheme.  The  network  Pump 
uses  a  similar  randomization  scheme  as  the  basic  Pump 
whose  details  are  presented  in  [6],  [7].  As  described  in  Sec¬ 
tion  2,  the  TLP  of  the  basic  Pump  delays  ACKs  based  on  a 
modified  exponential  random  distribution  whose  mean  is 
the  moving  average  of  the  session.  This  ACK  rate  controls 
the  input  rates,  through  the  handshake  protocol,  if  the  de¬ 
mand  rate  is  higher  than  the  ACK  rate. 

As  we  discussed  in  Section  3.1.2,  we  wish  to  make  sure 
that  the  number  of  messages  in  an  output  buffer  fluctuates 
around  the  Fair  size.  To  achieve  this,  we  modify  the  ACK 
scheme  from  the  basic  Pump.  The  way  the  basic  Pump 
controls  the  ACK  time  to  Low  can  be  written  as  follows: 
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[Tr  if  MA  -  Tr  <  0 

ACK  time  +  f^MA  -  7j],  time_  out)  otherwise 

where  Tr  is  the  same  as  in  Section  2,  and  /r[zWA  -  7j.]  is  a 
draw  from  a  random  distribution  as  also  described  in  Sec¬ 
tion  2.  (Note  that  there  is  only  one  session  in  the  basic 
Pump.)  Recall  that  Tr  is  the  time  between  when  the  a  mes¬ 
sage  is  sent  from  Low  to  when  the  message  is  placed  in  the 
output  buffer.  Hence,  a  random  delay  is  included  in  the 
ACK  time  in  addition  to  Tr  if  MA  -  Tr  >  0.  A  detailed  de¬ 
scription  can  be  found  in  [7]. 

We  now  describe  the  way  the  network  Pump  controls 
ACK  times  to  L,-  for  a  message  in  each  session.  Let  fr(x)  be  a 
draw  from  the  exponential  distribution  with  mean  x.  Define 


Q  z=fr(MA,j  -  T,)  +  k  •  (N  -  Fair  size) 

where  N  is  the  number  of  messages  in  buffer,,  at  the  time 
the  message  is  placed  in  buffer,,,  and  k  ■  (N  -  Fair  size)  is  a 
feedback  term.  Both  k  and  Fair  size  can  be  chosen  by  a  sys¬ 
tem  designer.  Note  that  the  moving  average  of  the  ACK 
times  from  H  to  the  network  Pump  is  computed  separately 
for  each  session.  For  session, y,  the  ACK  time  to  Low  for  each 
message  is: 

f  Tr  if  MA  -  T  <  0  or  Q  <  0 
ACK  time  =  t  /„  ;  , 

mm(Tr  +  Q,  time_  out]  otherwise 

We  now  elaborate  the  rationale  of  the  extra  term  k  ■  (N  -  Fair 
size)  in  Q.  As  long  as  L,  has  messages  to  send  to  Hy,  the  net¬ 
work  Pump  wants  to  keep  buffer, y  nonempty.  The  reason  is 
to  prevent  missing  the  round-robin  turn,  and  thus  to  give 
each  session  throughput  close  to  max-min  fairness.  There¬ 
fore,  when  the  number  of  messages  in  buffer^-  is  less  than 
the  Fair  size,  the  network  Pump  reduces  its  ACK  time  to  L, 
in  order  to  accelerate  the  input  rate,  as  seen  in  the  extra 
term.  On  the  other  hand,  if  buffer, ■■  is  often  full,  we  have 
covert  channel  problems  (see  Section  3.2),  Hence,  the  net¬ 
work  Pump  decreases  the  input  rate  by  increasing  the  ACK 
time  to  L,  when  the  number  of  messages  in  buffer, y  is  larger 
than  the  Fair  size. 

In  the  simulation  that  is  described  in  Section  4,  we 
choose  k  =  MA,,/ ( Fair  size)  (see  Section  4  for  the  discussion 
of  how  the  Fair  size  was  chosen  for  the  simulation).  Thus 

Q  =  /..(MA,,  -Tr)  +  MA-  \  v  N  .  ■  - 1  . 

Jr\  'i  r>  ‘i  Fair  size 


Therefore,  we  have 

avg(ACK  time )  »  Tr  +  avg(Q )  =  MAij  J  ' 

Note  that  avg(N)  is  close  to  the  Fair  size  due  to  the  second 
term  of  Q.  Thus,  we  have  avg(ACK  time)  ~  MAtj. 

3.1.4  Receivers 

Receivers  receive  messages  from  Lows  and  request  routing 
to  the  TLP.  Each  receiver  contains  /  slots  (size  one  buffers) 
so  that  the  inputs  from  one  session  do  not  interfere  with 
inputs  from  other  sessions.  Messages  in  the  slots  will  either 
be  routed  or  discarded  after  time_out  (if  there  is  no  output 
buffer  available). 


3.2  Design  Review 

In  this  section,  we  review  the  design  of  the  network  Pump 
and  explain  how  the  objectives  in  Section  1.2  are  satisfied. 
We  back  our  claims  on  performance,  fairness,  and  denial  of 
service  by  the  simulation  results  presented  in  Section  4. 

3.2.1  Reliability 

Due  to  the  reliability  protocol  requirement  that  was  speci¬ 
fied  in  Section  1.2  (i.e.,  ACK,  retransmission  of  the  same 
message  after  time_out,  and  message  ID),  the  network 
Pump  provides  as  much  reliability  as  TCP.  Also,  the  High 
ACK  of  the  Pump  can  be  realized  as  an  ACK  of  an  applica¬ 
tion  layer  protocol  to  provide  reliability  at  the  application 
layer.  There  are  some  secure  system  protocols  which  do  not 
use  acknowledgements,  but  they  are  not  reliable  [19],  [2]. 

3.2.2  Performance 

The  network  Pump  does  not  hurt  performance 
(throughput).  Consider  the  following  two  cases  where  out¬ 
put  link  capacities  are  not  a  bottleneck: 

•  Demand  rate  is  faster  than  the  service  rate.  The  network 
Pump's  ACK  rate,  which  is  tied  to  the  moving  aver¬ 
age  of  the  server  will  slow  down  input  to  match  the 
servers.  However,  this  will  not  degrade  performance 
because  the  throughput  will  be  determined  by  the 
service  rate  which  is  the  performance  bottleneck. 

•  Demand  rate  is  slower  than  the  service  rate.  The  network 
Pump's  ACK  rate  will  not  slow  down  the  input  rate  in 
this  case.  Hence,  there  is  no  effect  on  performance. 

If  the  output  link  capacities  are  a  bottleneck,  the  network 
Pump's  max-min  fairness  criteria  and  the  moving  average 
construction  assures  us  that  performance  is  not  penalized 
(Section  3.1.1).  Hence,  the  network  Pump  does  not  affect  the 
throughput  unless  the  network  Pump  itself  is  the  bottleneck. 

3.2.3  Fairness 

The  network  Pump  uses  a  round-robin  scheduling  scheme 
which  achieves  max-min  fairness  at  each  THPy  if  all  inputs 
can  accumulate  enough  messages  at  output  buffers.  The 
network  Pump's  modified  moving  average  construction 
that  was  described  in  Section  3.1.3  encourages  all  inputs  to 
send  as  many  messages  as  possible  up  to  the  Fair  size.  Hence, 
the  network  Pump  strives  to  achieve  max-min  fairness. 

3.2.4  Covert  Channel  Analysis 

A  major  reason  that  the  network  Pump  uses  a  randomized 
ACK  stream,  aside  from  fair  congestion  control  is  to  mini¬ 
mize  the  threat  of  covert  communication  from  a  High  to  a 
Low.  Ideally,  a  secure  computer  system  does  not  allow  a 
communication  channel  from  a  high  level  user/ process  to  a 
low  level  user/process  [10].  However,  in  reality,  unless  we 
want  a  nonresponsive  or  nonreliable  system,  such  covert 
channels  are  a  fact  of  life.  Given  that,  one  must  try  to  find 
ways  to  minimize  illicit  information  leakage  from  such  cov¬ 
ert  channels.  The  covert  channels  that  concern  us  in  this 
paper  are  timing  channels  [12],  [15],  [24] — these  are  covert 
channels  where  the  output  symbols  are  distinguished  by 
their  different  time  values. 

The  specific  timing  channels  that  concern  us  have  been 
discussed  in  detail  in  other  papers  [6],  [7],  [13],  [16],  so  we 
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present  only  a  brief  review  here.  Let  us  start  off  with  a  sim¬ 
ple  scenario:  a  single  low  (Low)  and  a  single  high  (High) 
with  a  store  and  forward  buffer  (SAFES)  between  them.  Low 
sends  a  message  to  the  SAFB.  When  this  message  is  stored 
in  the  SAFB,  the  SAFB  sends  an  ACK  back  to  Low  and  then 
Low  can  send  its  next  message  to  the  SAFB.  The  SAFB  at¬ 
tempts  to  send  the  message  to  High  and  when  High  has 
successfully  received  the  message  from  the  SAFB,  High 
sends  an  ACK  to  the  SAFB  and  the  message  is  removed 
from  the  SAFB.  For  obvious  reliability  concerns,  we  do  not 
allow  Low  to  write  over  messages  in  the  SAFB  before  they 
have  been  read  out  by  High.  Therefore,  when  the  buffer  is 
full  it  stops  receiving  messages  from  Low.  This  opens  up 
what  is  referred  to  as  the  full  buffer  channel  (FBC)  between 
High  and  Low.  High,  by  intentionally  slowing  or  stopping 
its  receiving  of  messages  from  the  SAFB,  can  cause  the 
SAFB  to  become  full.  Then  High  can  remove  messages  to 
allow  space  to  open  up  on  the  SAFB  and  for  Low  to  again 
receive  an  ACK  from  the  SAFB  and  send  new  messages. 
Therefore,  High  can  manipulate  the  timing  of  the  ACK 
stream  to  Low  from  the  SAFB.  Let  us  do  a  worst-case  in¬ 
formation  theoretic  analysis  of  the  FBC  to  see  how  much 
information  can  actually  be  leaked  from  High  to  Low  and 
hence  how  insecure  our  system  may  be. 

The  FBC  is  a  timing  channel.  To  exploit  the  FBC  it  is  as¬ 
sumed  that  Trojan  horses  (malicious  software  in  both  Low 
and  High)  are  in  the  computer  system.  The  Trojan  horses 
control  when  Low  sends  a  message  and  when  High  sends 
an  ACK  back  to  the  SAFB. 

•  A  Trojan  horse  fills  the  SAFB  by  (High)  not  removing 
messages  from  the  SAFB. 

•  Now  that  the  SAFB  is  full,  a  noiseless  timing  channel 
exists  between  High  and  Low.  Furthermore,  this 
noiseless  channel  exists  as  long  as  the  SAFB  is  full. 

•  Now  Low  sends  a  message  to  the  SAFB.  The  SAFB 
cannot  send  an  ACK  back  to  Low  until  a  spot  opens 
up  on  the  SAFB.  If  High  happens  to  remove  a  mes¬ 
sage  as  soon  as  (or  before)  Low  sends  a  message,  then 
Low  only  waits  an  overhead  time  Ov  for  an  ACK.  We 
assume  that  High,  by  removing  messages  from  a  full 
SAFB,  can  affect  the  ACK  time  to  Low  in  increments 
of  ie,i-  0, 1,  2,  ....  Assuming  Trojan  horses  know  the 
size  of  the  SAFB  (i.e.,  n)  and  how  fast  the  Trojan  horse 
can  send  a  message,  High  knows  that  Low  has  filled 
the  SAFB  and  has  just  sent  a  new  message  to  the 
SAFB.  If  Low  gets  an  ACK  at  time  Ov  +  z’e.  Low  inter¬ 
prets  the  signal  as  the  (i  +  l)st  symbol.  Since  every 
time  Low  receives  an  ACK,  the  SAFB  is  full  again, 
and  Low  can  then  send  its  new  message — High  can 
noiselessly  send  symbols  again. 

With  this  example  we  are  looking  at  a  worst-case  sce¬ 
nario.  High  will  try  to  send  symbols  as  quickly  as  possible, 
hence  the  time  values  of  Ov  +  ie.  Of  course  this  allows  un¬ 
bounded  response  times.  Real  systems  have  timeouts  and 
we  assume  that  the  timeouts  in  question  are  very  large  in 
comparison  to  O.0  >  e,  so  that  examining  a  communication 
channel  with  i  bounded  changes  the  analysis  very  little 
from  assuming  that  i  is  unbounded.  The  time  units  of  our 
system  are  such  that  e  is  an  integer,  i.e.,  e  is  an  integer 


number  of  system  clock  ticks  (either  reading  from  a  system 
real-time  clock  or  instruction  counts  from  a  tight  loop).  The 
channel  capacity  [23]  of  this  channel  is  given  by 

log  N(k) 

C  =  lim  sup - t - bits  per  clock  tick 

k — 

where  the  logarithms  are  base  two  and  N(k)  is  the  number 
of  distinct  sequences  of  symbols  (ACK  times)  that  take  a 
total  of  time  k.  It  can  be  shown  [23],  [12],  [13],  [16]  that 

C  =  log  co,  where  co  is  the  positive  zero  of  1  -  ( x~0v  +  x~e). 
The  polynomial  arises  from  the  limiting  behavior  of  the 
recurrence  relation 

Nik)  =  Nik  -  Cy  +  Nik  -  iOv  +  e))  +  Nik  -  (Ov  +  2e))  +  •  ■  •. 

O, 

Define  cj  by  =  q .  Note  that  q  need  not  be  an  integer. 
By  changing  variables  and  letting  y  =  we  see  that  co  is  the 
positive  zero  of  1  -  (y_<?  +  yJ).  Unfortunately,  the  only 
closed  form  solution  for  such  polynomials  [13]  involve  spe¬ 
cial  functions.  For  certain  special  cases  such  as  q  =  1  we  can 
obtain  the  trivial  closed  form  solution  that  C  =  1  /  e.  Simi- 

!  1  +  a/5 

larly  for  q  =  2,  we  have  C  =  e  log  — ^ — - . 

The  basic  Pump,  which  deals  with  a  single  Low  and  a 
single  High,  was  designed  to  minimize  the  threat  of  the 
FBC  by  modifying  the  SAFB  by  using  probabilistic  ACK 
times.  The  probabilistic  arrival  times  of  the  ACKs  introduce 
noise  into  the  timing  channel.  Also,  the  basic  Pump  pre¬ 
vents  the  buffer  from  becoming /staying  full.  These  two 
effects,  the  noise  and  the  fact  that  the  buffer  is  hardly  ever 
full,  severely  diminish  the  channel  capacity  of  various  ex¬ 
ploitations  of  the  FBC.  Bounds  on  the  actual  covert  exploi¬ 
tation  of  the  basic  Pump  are  given  by  capacity  reduction 
formulas  in  [6]  and  more  precisely  in  [7].  In  brief,  a  rela¬ 
tionship  between  the  buffer  size  n  and  the  moving  average 
parameter,  m,  was  given  with  respect  to  the  desired  percent 
reduction  of  the  covert  channel  capacity.  Hence,  either 
analytically  or  numerically,  we  have  a  way  to  measure  the 
maximal  information  leakage  from  High  to  Low  in  the  basic 
Pump.  We  will  show  that  these  reductions  also  hold  for 
covert  channel  exploitations  of  the  network  Pump. 

In  the  network  Pump,  our  Trojan  horse  scenario  is  that 
one  particular  1 1,  and  one  particular  L,  are  in  cahoots  via 
cooperating  Trojan  horses  (recall  that  we  are  looking  at  the 
situation  where  the  Lows  (Highs)  do  not  communicate 
among  themselves) — thus  we  again  have  the  potential  for 
the  FBC.  However,  the  fact  that  there  are  other  users  of  the 
network  Pump  means  that  noise  is  introduced  into  the  FBC 
which  does  not  occur  in  the  case  of  one  Low  and  one  High. 
Thus,  the  covert  channel  analysis  from  the  basic  Pump  still 
holds  for  the  network  Pump  as  a  worst-case  scenario  (we 
can  very  conservatively  replace  the  buffer  size  of  the  basic 
Pump,  n,  by  the  Fair  size  in  the  capacity  reduction  formulas 
[7]).  This  is  because  in  the  network  Pump,  instead  of  just 
attempting  to  keep  the  total  buffer  from  become  full,  we 
attempt  to  keep  the  total  buffer  around  (the  number  of  ac¬ 
tive  sessions  xFair  size).  Hence,  for  a  misbehaving  session 
to  fill  the  total  buffer,  and  thus  exploit  the  FBC,  it  requires 
that  session  to  fill  the  unused  total  buffer  spaces  which  are 
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at  least  Fair  size  in  number  (see  Section  3.1.2).  Therefore,  we 
can  use  the  capacity  reduction  formulas  from  [7],  where 
there  is  one  Low  and  one  High  as  an  upper  bound.  These 
reduction  formulas  tell  us  how  to  choose  the  Fair  size  and 
the  moving  average  parameter,  m,  to  ensure  that  any  covert 
channel  capacity  is  within  a  specified  bound.  This  bound 
becomes  even  more  conservative  as  I  and  /  increase  due  to 
the  increasing  noise  of  multiple  users  being  on  the  system. 
Therefore,  given  values  of  Ov  and  e,  we  can  choose  a  Fair 
size  and  moving  average  parameter,  m,  to  reduce  the  po¬ 
tential  covert  channel  capacity  to  within  a  specified  value. 

In  the  basic  Pump  there  is  a  statistical  channel  [17]  from 
High  to  Low,  when  the  buffer  is  not  full,  caused  by  Low 
attempting  to  correlate  the  ACK  times  to  High's  actions.  As 
the  number  of  terms  making  up  the  moving  average  grows, 
this  correlation  decreases,  and  hence  the  channel  capacity 
decreases.  The  same  holds  as  well  for  the  network  Pump 
and  again  the  multiple  users  introduce  spurious  noise 
which  further  serves  to  confound  any  meaningful  inter¬ 
pretation  of  the  ACK  times.  Also,  the  Fair  size  further  frus¬ 
trates  correlation  attempts  by  L,.  Therefore,  the  bounds 
from  the  basic  Pump  again  hold. 

Finally,  the  network  Pump  (as  well  as  the  basic  Pump)  is 
sensitive  to  the  small  message  criterion  [18],  By  this  we 
mean  even  if  one  has  a  channel  with  small,  or  even  zero, 
capacity  it  might  still  be  possible  to  send  small,  possibly 
noisy,  messages  relatively  quickly.  The  network  Pump,  be¬ 
cause  of  its  buffer  management  and  randomization  scheme, 
is  designed  to  thwart  an  attempt  at  sending  meaningful 
short  messages,  see  [7,  Section  4]  for  details. 

3.2.5  Denial  of  Service 

In  the  network  environment  denial  of  service  can  occur  in 
the  following  two  cases: 

1)  A  server  slows  down. 

2)  An  input  sends  messages  faster  than  the  rate  that  the 
intended  server  can  handle  them. 

In  these  cases,  the  shared  resources  will  be  monopolized  by 
this  specific  session  so  that  other  sessions  cannot  use  re¬ 
quired  resources. 

The  above  cases  will  not  happen  if  the  network  Pump 
mediates  between  the  Lows  and  Highs  because  the  network 
Pump  monitors  the  servers'  activities  and  tracks  service 
rates.  The  service  rate  will  be  reflected  in  the  ACK  rate  to  Lf 
through  the  moving  average  construction.  Due  to  the  net¬ 
work  Pump's  handshake  protocol  and  moving  average 
construction,  inputs  (Lows)  cannot  send  any  more  than  the 
servers  (Highs)  can  handle. 

4  Simulation  Results 

To  substantiate  our  claims  on  performance,  fairness  and  de¬ 
nial  of  service,  simulation  experiments  have  been  conducted. 

4.1  Simulation  Set  Up 

In  our  simulation  scenario,  there  are  three  Lows  (Lv  L2,  L3) 
and  three  Highs  (Ht,  H2,  H3);  hence  nine  sessions.  The  ca¬ 
pacities  of  all  input  and  output  links  are  1.0.  All  demanded 
inputs  have  Poisson  arrival  distributions.  Demand  rates 


from  /.[  are  dji  -  0-5/  A, 2  =  0.3,  213  =  0.2,  the  demand  rates 
from  h2  are  =  0.4,  d22  =  0.4,  A&  =  0.2,  and  the  demand 
rates  from  L3  are  =  0.4,  =  0-5,  J33  =  0.1  (see  Fig.  7). 

All  Highs  have  2-Erlang  distributed  service  rates.  The  2- 
Erlang  distribution  is  often  used  to  model  the  time  to  com¬ 
plete  a  task  [81.  For  the  benign  case  all  service  rates  are  set 
to  2.0  (to  demonstrate  the  output  links  being  the  bottle¬ 
necks,  any  value  greater  than  1.0  would  suffice).  For  denial 
of  service  simulation,  service  rates  are  jun  =  2.0,  /7,2  =  0.1, 
and  /ji3  =  2.0  for  i  =  1, 2,  3. 


Mil  -  2.0 


|i.j2  =  2.0  for  benign  case 
|ii2  =  0. 1  for  denial  of  service 


Mb  =  2-0 


Fig.  7.  The  simulation  scenario. 


The  performance  and  fairness  of  the  following  two  sys¬ 
tems  and  the  "ideal"  case  are  compared  under  different 
total  output  buffer  sizes. 

•  The  network  Pump  as  described  in  Section  3.  The  last 
30  High  ACK  times  are  used  to  compute  the  moving 
average  (i.e.,  m  -  30)  and  the  Fair  size  per  session  was 
set  to  1/10  of  the  total  output  buffer  size.  Note  that 
there  are  nine  sessions  in  our  scenario. 

•  The  Nonpump.  This  is  the  same  as  the  network  Pump 
(still  has  the  handshake  protocol)  except  that  it  does  not 
have  the  moving  average  or  probabilistic  construction. 
(Thus,  output  buffer  space  is  allocated  to  each  session 
on  a  first  come  first  served  basis.)  In  other  words, 
ACKs  will  be  sent  to  Lows  as  soon  as  the  message  is 
routed.  Hence,  demand  rates  will  be  forcibly  adjusted 
to  the  realized  rate  only  when  there  are  no  available 
output  buffers.  The  purpose  of  this  system  is  to  demon¬ 
strate  the  importance  of  congestion  control. 

•  The  ideal  case  is  where  the  max-min  fairness  rates  are 
achieved  over  the  output  links.  The  max-min  rates  for 
Hf  are  (1/3, 1/3, 1/3),  for  H2  they  are  (0.3,  0.35,  0.35), 
and  for  H3  they  are  (0.2,  0.2,  0.1).  Hence,  these  are  the 
ideal  versions  to  which  we  compare  the  network 
Pump  and  the  Nonpump. 

4.2  Simulation  Results  in  the  Benign  Case 

In  the  benign  case  (i.e.,  inputs  and  outputs  behave — no 
Trojan  horses  are  present),  there  is  not  much  of  a  perform¬ 
ance  difference  between  the  network  Pump  and  the  Non¬ 
pump  even  though  the  network  Pump  performs  slightly 
better  than  the  Nonpump.  This  slight  performance  differ¬ 
ence  comes  from  the  congestion  control  mechanism.  Since 
the  Nonpump  has  little  congestion  control,  some  inputs  still 
send  more  messages  than  the  intended  server  can  handle. 
This  causes  an  unfair  sharing  of  resources  and  degrades 
performance.  This  effect  will  be  magnified  under  the  denial 
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50  100  150  200  250  50  100  150  200  250  50  100  150  200  250 

Total  Buffer  Size  Total  Buffer  Size  Total  Buffer  Size 


Fig.  8.  Throughput  of  session12.  Fig.  9.  Throughput  of  session22.  Fig.  10.  Throughput  of  session32. 


50  100  150  200  250  50  100  150  200  250  50  100  150  200  250 

Total  Buffer  Size  Total  Buffer  Size  Total  Buffer  Size 


Fig.  11.  Throughput  of  sessionn.  Fig.  12.  Throughput  of  session2i.  Fig.  13.  Throughput  of  session31. 

Note  that  the  Pump  and  the  Idea!  curves  are  virtually  identical  in  Figs.  11,12,  and  13. 


50  100  150  200  250  50  100  150  200  250  50  100  150  200  250 

Total  Buffer  Size  Total  Buffer  Size  Total  Buffer  Size 


Fig.  1 4.  Throughput  of  session13.  Fig.  15.  Throughput  of  session23.  Fig.  1 6.  Throughput  of  session33. 


of  service  attack.  Fig.  8,  Fig.  9,  and  Fig.  10  show  the  perform¬ 
ance  and  fairness  among  sessions  that  send  messages  to  H2. 

Note  session12  achieves  its  demand  rate  as  realized  rate 
(0.30).  Hence,  the  jitter  in  Fig.  8  is  from  the  probabilistic 
nature  of  the  input  rather  than  any  effects  from  routing  de¬ 
vices.2  This  probabilistic  jitter  slightly  affects  the  through¬ 
put  of  other  sessions  (Fig.  9  and  Fig.  10). 

Fig.  9  and  Fig.  10  also  show  the  effect  of  the  scheduler, 
and  the  size  of  the  output  buffer  and  the  Fair  size  to  the 
fairness  and  throughput  of  each  session,  since  0.4  and  0.5 
are  both  greater  than  0.35.  As  the  size  of  output  buffer 
grows  the  throughput  approaches  its  ideal  (fairness)  rate. 

Even  though  we  do  not  show  the  performance  of  other 
sessions,  the  network  Pump  performs  very  well  (basically 
the  same  as  in  Figs.  11, 12, 13, 14, 15,  and  16). 

2.  The  simulator  never  exactly  generates  a  rate  of  0.3,  hence  the  jitter. 


4.3  Simulation  Results  Under  Denial  of 
Service  Attack 

To  show  the  effect  of  a  denial  of  service  attack,  we  slow 
down  the  service  rate  (i.e.,  ul2  =  0.1)  of  one  High,  namely 
Hr  Figs.  11, 12, 13, 14, 15,  and  16  show  the  performance  and 
fairness  comparison  between  the  network  Pump  and  the 
Nonpump.  The  performance  of  the  network  Pump  is  hardly 
affected  by  the  attack.  However,  the  performance  of  the 
Nonpump  is  greatly  affected.  The  main  reason  for  the  deg¬ 
radation  of  performance  is  that  all  output  buffer  space  is 
occupied  by  sessions  that  send  messages  to  H2  so  that  the 
rest  of  sessions  have  to  wait  a  long  time  to  obtain  them. 

Fig.  11,  Fig.  12,  and  Fig.  13  show  the  throughputs  of  ses¬ 
sions  to  Hj. 

These  figures  (Figs.  11,  12,  and  13)  show  no  jitter  of 
throughput  as  the  total  buffer  size  increases.  This  shows 
that  the  probabilistic  nature  of  inputs  are  all  hidden  because 


KANG  ET  AL.:  A  NETWORK  PUMP 


337 


all  input  (demand)  rates  to  Hi  are  greater  than  its  realized 
rate  and  messages  are  always  waiting  for  their  turn  at  the 
output  buffer3  (the  round-robin  scheme  takes  a  message 
from  each  buffer  in  turn  and  does  not  pass  any  buffer  be¬ 
cause  they  always  have  a  message  ready  to  send). 

Fig.  14,  Fig.  15,  and  Fig.  16  show  the  throughputs  of  dif¬ 
ferent  inputs  to  H3.  Again  the  jitter  of  throughput  is  from 
the  probabilistic  nature  of  inputs  rather  than  the  effect  of 
different  buffer  sizes. 

We  do  not  show  throughputs  of  session12,  session22,  ses- 
sion32  because  under  the  denial  of  service  attack  all  cases 
have  throughput  values  around  0.033. 

5  Discussion 

This  paper  describes  the  need  for  a  secure  device  that  can 
route  messages  from  (multiple)  Lows  to  (multiple)  Highs. 
Even  though  abstract  composition  problems  have  been  well 
studied  [11],  this  paper  shows  that  the  actual  design  of  such 
a  device  is  quite  complicated.  This  secure  device  should  not 
only  meet  the  requirements  of  conventional  network  rout¬ 
ers  such  as  performance,  reliability,  and  fairness,  but  also 
the  requirements  of  security,  such  as  minimal  impact  from 
covert  channels  and  denial  of  service  attacks.  The  network 
Pump  that  we  introduced  in  this  paper  can  balance  the 
above  requirements. 

It  is  interesting  to  note  that  the  network  Pump's  use  of 
indirect  acknowledgments  is  similar  to  ideas  put  forth  in 
the  mobile  computing  community  [1],  Further,  the  network 
Pump's  stable  storage  is  along  the  lines  of  "packet  caching" 
used  in  [25], 

One  of  our  future  plans  includes  designing  and  building 
the  network  Pump  on  top  of  the  ATM  layer.  We  are  also 
investigating  extending  the  network  environment  described 
in  this  paper  to  deal  with  a  more  general  lattice-type  secu¬ 
rity  structure.  We  refer  to  this  as  the  "generalized  Pump." 
Note  that  if  we  allow  Lows  (Highs)  to  conspire  then  we 
must  redo  our  covert  channel  capacity  analysis.  We  leave 
this  as  future  work. 
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